Account Aggregation
歴史は古く1990年代半ばから存在する
口座の情報の取得方法
金融機関によって参照権限だけ渡せるケースと、資金移動までできてしまうケースがある
サードパーティのサービスを使う
1700も金融機関があると毎日どこかしらリニューアルが行われている計算になります。
実際、毎週月曜になるといくつかの金融機関でリニューアルが行われていて、データが取得出来なくなっている事がよくあります。少し前にとある金融機関に新規対応したのですが、その翌週早速リニューアルをされた時は泣きながら対応しました。。。
取得失敗時にRedmineのチケットを自動起票する
これまでも単独で資金移動が可能となるログイン情報は原則としてお預かりしない方針を採用していましたが、例外としていた一部の金融機関口座の自動取得に関しても、一切お預かりしないようにセキュリティ方針を変更しました。
ほとんどの金融機関においては振込などの資金移動時にはワンタイムパスワードやトークンや第二暗証番号などが追加で確認されるようになっており、しっかりとした権限分離が行われています。 本当にごく一部の金融機関においてはその権限分離が行われておらず、ログインに必要な情報で資金移動まで行えてしまうケースがありました。
日本初、個人向け国内銀行口座すべてに対応完了
3年かけて達成
法人向けの金融機関の場合、金融機関から利用者に配布される電子証明書があったりする こちらの手元にはなく、お客さん側のPCに入っていて、それを使って通信しないといけないという前提があります。そのためにお客さんのPCにソフトをインストールしてもらって通信するという仕組みがあり、そこのメンテを私がしています。日本の法人金融機関はほぼこういった仕組みになっています。 ずっと5名ぐらい
日々2,3件のチケット自動起票がある
MFクラウド経費で、手入力を強いていたサービスのアグリゲーション元をメールにした
そもそもAPI連携できないサービス、複雑な認証フローを要求されるサービス
こういった特徴のサービスについては連携先として追加するのが難しく、ユーザに手入力でのデータ作成を強いてしまっている、というのがこれまでの現状でした。
新たな連携追加の手段がないか模索し始めました。 最近ではチャットツールなども積極的に活用されるようになってきましたが、ビジネスの世界ではまだまだ連絡の方法としてメールでのやりとりも主流です。 メール取込では、特に領収書などがメールで送受信されている点に着目しました。 メールのやりとりを起点としたアカウントアグリゲーションを実現し、より広範囲のサービスで連携先追加や会計データの作成などを自動化すること目指しています。
ohbarye.icon 自然言語で書かれたメールの処理に苦戦している話が出ているが2023年ならLLMの活用ができそう 証憑自動取得